1. Field of the Invention
This invention relates to communications and, more particularly, to a binary protocol for session initiation in a wireless communications system.
2. Description of Related Art
Two communication technologies are commonly used by the general public; cellular telephony and the Internet. Cellular telephony provides its users with the freedom of mobility—the possibility of being reached with reasonable service quality regardless of location. However, the main service provided by cellular telephony is speech. While flexibility for all kinds of usage (speech, data, video, audio, etc.) has been Internet's strength, its focus has been on fixed connections and relatively large terminals, and the quality of some services (such as Internet telephony) has generally been poor. As technology advances, the Internet and cellular technologies are merging. Future cellular “phones” may contain an IP-stack (internet protocol) and support voice over IP in addition to web-browsing, e-mail, etc. In essence, the Internet is going mobile, or cellular systems are becoming much more than telephony, depending on the point of view.
FIG. 1 shows a conventional network 10 which can be divided into a radio access network (RAN) 12 and a core network (CN) 14. The RAN 12 comprises the equipment used to support wireless interfaces 16a-b between a wireless unit 18a-b and the network 10. The RAN 12 includes NodeBs or base stations 20a-c connected over links (Iub links) 21a-c to radio network or base station controllers (RNC) 22a-b. The interface between the base station and the RNC is referred to as the Iub interface or link, and the interface between two RNCs is referred to as the Iur interface. Currently, both the Iub and Iur interfaces are based on ATM (a synchronous transfer mode), and ATM switches are allowed between NodeBs and RNCs.
The core network 14 includes the network elements that support circuit-based communications as well as packet-based communications. In establishing a circuit channel to handle circuit-based communications between the wireless unit 18b and a public switched telephone network (PSTN) 24 or another wireless unit, the base station 20b receives (in the uplink) and transmits (in the downlink), the coded information (circuit voice or circuit switched data) over the wireless interface or link 16b. The RNC 22b is responsible for frame selection, encryption and handling of access network mobility. The RNC 22b forwards the circuit voice and circuit switched data over a network, such as an ATM/IP network to a 3G mobile switching center (MSC) 30. The 3G-MSC 30 is responsible for call processing and macromobility on the MSC level. The 3G-MSC 30 establishes the connectivity between the wireless unit 18b and the PSTN 24.
Commonly used terms in this technical field are “all-IP” and “IP all the way”. These terms both relate to the case where an IP is used end to end, even if the path involves cellular links, and IP is also run over the radio hop(s). This is done for all types of traffic, both the user data (e.g. voice or streaming) and control signaling data, either SIP (session initiation protocol) or RTSP (real time streaming protocol). A benefit of this is the service flexibility introduced by IP combined with the freedom provided by continuous mobility. The downside is the relative large overhead the IP protocol suite typically introduces, e.g. due to large headers and text-based signaling protocols.
In cellular systems, the scarce radio resources should be used in an efficient way. It should be possible to support a sufficient number of users per cell, otherwise costs will be prohibitive. Frequency spectrum and thus bandwidth are costly resources in cellular links and should be used carefully.
The ROHC (RObust Header Compression) working group has successfully solved the problem of reducing bandwidth requirements for the header parts of real time protocol (RTP), user datagram protocol (UDP), and IP packets. With this obstacle removed, new possibilities of enhancing mobile internet performance arise. One of these relates to application signaling protocols. Protocols such as SIP, RTSP, and SDP (session description protocol) are typically used to set up and control applications in a mobile Internet. However, the protocol messages are large in size and create delays due to their request/response nature. Compression of these messages would increase spectrum efficiency and reduce transmission delay.
The SIP is an application layer protocol for establishing, modifying and terminating multimedia sessions or calls. These sessions include Internet multimedia conferences, Internet telephony and similar applications. SIP can be used over either TCP (Transmission Control Protocol) or UDP. SIP is a text based protocol, using ISO 10646 in UTF-8 encoding.
The SDP may be used to advertise multimedia conferences and communicate conference addresses and conference tool-specific information. The SDP is also used for general real-time multimedia session description purposes. SDP is carried in the message body of SIP and RTSP messages. SDP is text based using the ISO 10646 character set in UTF-8 encoding.
The RTSP is an application level protocol for controlling delivery of data with real-time properties, such as audio and video. RTSP may use UDP or TCP (or another protocol) as the transport protocol. RTSP is text based using the ISO 10646 character set in UTF-8 encoding.
The above protocols have many similarities. These similarities have implications on solutions to the problems they create in conjunction with the cellular radio access. Their similarities include the following:                Requests and reply characteristics. When a sender sends a request, it stays idle until it has received a response, hence, it typically takes a number of round trip times to conclude a SIP, SDP, or RTSP session.        They are ASCII based. Thus to represent the value 230, 3*8=24 bits are used. A binary representation of the same value, by comparison, would require only 8 bits.        They are large in size in order to provide the necessary information to the session participants.        
SIP and RTSP share many common header field names, methods and status codes. Their traffic patterns are also similar. The signaling is carried out primarily during the setup phase. For SIP, this means that the majority of the signaling is carried out to set up a phone call or multimedia session. For RTSP, the majority of the signaling is done before the transmission of application data.
As described above, the SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include internet telephone calls, multimedia distribution and multimedia conferences.
SIP invitations are used to create sessions, which carry session descriptions that allow participants to agree on a set of compatible media types. SIP may make use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP is ASCII based and can run over multiple transport protocols. Since SIP is ASCII based, a parser is required to interpret the various fields.
Typical SIP messages are very large. In wireless network, airlink resources are limited. Thus, the call setup time can potentially be long over a 9.6 Kbps wireless link. There are on-going activities to design compression algorithms for SIP. The need for solving the problems caused by the signaling protocol messages is made clear by looking at a typical SIP/SDP Call Setup sequence over a narrow band cellular channel and by studying results from a simple system capacity example. These results indicate that there also would be a gain to the system capacity by reducing the size of the single protocol messages.
FIG. 2 illustrates an example of an SIP client new registration procedure in accordance with the conventional SIP protocol.
An exemplary Register F1 message (without authentication) for conventional SIP is as follows:    Register sip: ss2.wcom.com SIP/2.0    Via: SIP/2.0/UDP userB@there.com:5060    From: LittleGuy <sip: userB@there.com>    To: LittleGuy <sip: userB@there.com>    Call-ID: 123456789@there.com    CSeq: 1 REGISTER    Contact: <sip:userB@111.111.112.113>    Contact: <sip:+1-972-555-2222(gwl.wcom.co;user=phone>    Contact: tel:+1-972-555-2222    Content-Length: 0.
An exemplary 401 Unauthorized F2 message for conventional SIP is as follows:    SIP/2.0 401 Unauthorized    Via: SIP/2.0/UDP there.com:5060    From: LittleGuy <sip: userB@there.com>    To: LittleGuy <sip: userB@there.com>    Call-ID: 123456789@there.com    CSeq: 1 REGISTER    WWW-Authenticate: Digest Realm=“MCI WorldCom SIP”    domain=“sip:ss2.wcom.com”, nonce=“ea9c8e88d84f1cec4341ae6cbe5a359”,    opaque=“”, stale=FALSE, algorithm=“md5”    Content-Length: 0.
An exemplary Register F3 message for conventional SIP is as follows:    Register sip: ss2.wcom.com SIP/2.0    Via: SIP/2.0/UDP there.com:5060    From: LittleGuy <sip: userB@there.com>    To: LittleGuy <sip: userB@there.com>    Call-ID: 123456789@there.com    CSeq: 2 REGISTER    Contact: <sip:userB@111.111.112.113>    Contact: <sip:+1-972-555-222@gwl.wcom.co;user=phone>    Contact: tel:+1-972-555-2222    Authorization: Digest username=“UserB”,    realm domain=“MCI WorldCom SIP”,    nonce=“ea9c8e88d84f1cec4341ae6cbe5a359”, opaque=“”,    uri=“sip.ss2.wcom.com”, response=“dfe56131d1958046689cd83306477ecc”    Content-Length: 0.
An exemplary 200 OK F4 message for conventional SIP is as follows:    SIP/2.0 200 OK    Via: SIP/2.0/UDP there.com:5060    From: LittleGuy<sip:userB@there.com>    To: LittleGuy <sip: userB @there.com>    Call-ID: 123456789@there.com    CSeq: 2 REGISTER.
As can be seen above, many of the field are populated with long, ASCII character strings, which require extra bandwidth cause service setup delays.